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1 THE CLERK: Calendar number 20, Mr. Lanza. 

2 MR. LANZA: Good morning. 

3 JUDGE HOMERE: Good morning. Counselor. You have 20 minutes 

4 and feel free to begin whenever you're ready. 

5 MR. LANZA: Thank you. Thank you. My name is John Lanza, 

6 PTO registration number 40060, and I represent Citrix Systems in appeal 

7 2008-2771. This appeal comes to this board on the rejection of all pending 

8 claims as obvious in view of three prior art references. The claims are 

9 currently pending in serial number 09866375. 

10 Citrix Systems asks this board to reverse the examiner's rejection of 

1 1 all the pending claims as obvious and remand this application back to the 

12 examiner with instructions to allow it over the prior art of record. 

1 3 JUDGE COURTENAY: I do have to say, we have the power to 

14 affirm or reverse, or affirm in part, but the examining corps makes the 

15 ultimate decision as to what is allowed. We don't allow any cases here at the 

16 Board. 

17 MR. LANZA: Understood. Thank you. 

1 8 JUDGE COURTENAY: Could you go to the preamble issue to 

19 begin; that would be helpful for us? I understand that the examiner, for the 

20 first time in the prosecution history, he's saying that he's not giving certain 

21 limitations in the preamble patentable weight? 

22 MR. LANZA: That is what it appears to be. In his examiner's reply, 

23 the examiner stated twice ~ sorry, the examiner's answer, the examiner 

24 stated twice that limitations from the specification are not read into the 
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1 claims and that the preamble had not been given patentable weight because 

2 the recitation that we were relying on occurs in the preamble 

3 If we can turn to the claims briefly. And I thank you for bringing this 

4 issue up, because I admit that I was struggling with ~ I've got my argument, 

5 but now I have this new issue that I have to deal with, so I appreciate having 

6 the chance to just deal with -- 

7 JUDGE COURTENAY: Well, we do commend you for the proper 

8 use of a Reply Brief. The examiner has raised a new issue in the Answer for 

9 the first time and you have properly responded to it in the Reply Brief. 

10 MR. LANZA: Thank you. It's our position that the claims, as they're 

1 1 currently pending, the preamble is limiting for two reasons. One, the claim 

12 elements rely on the preamble for antecedent basis, which I believe is a well- 

13 settled basis for viewing the preamble as a claim limitation. There's also a 

14 doctrine that we refer to in our reply brief that states that if the applicant 

15 relies on the preamble in his or her arguments for patentability, that that is ~ 

16 that is then an indication that the preamble should be considered a claim 

17 limitation. I believe that's the Catalina Marketing case that we pointed to in 

1 8 our Reply Brief. 

19 And if we ~ if we look at claim 1, claim 12 is similar. But claim 1 

20 recites a method for controlling by a server the formation of an off- screen 

21 surface at a client, and then I'll allay that and we'll look at the first claim 

22 element instructing the client to select a first memory region. There's no 

23 antecedent basis for client other than in the preamble, and so we have always 

24 viewed this claim ~ we continue to view this claim as a client server 
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1 implementation where the server is instructing the client to perform specific 

2 tasks. 

3 The server is instructing the client to create or form an off-screen 

4 surface buffer in its memory. It then transmits in the second step an indicia 

5 of some graphical data to the client. Graphical data is referred to in the 

6 specification at paragraph five as, for example, bit-mapped graphical data, 

7 encoded bitmaps, glyphs and line data. 

8 The reason that an indicia of the graphical data is sent to the client is 

9 that this entire application is specifically directed to techniques to minimize 

10 the bandwidth necessary to communicate between a client and a server. The 

1 1 server then instructs the client to copy the graphical data associated with the 

12 indicia to a particular location in that first memory region that it has been 

13 instructed to set up. 



14 So a bitmap is sent down. It's cached at the client. There's a cache tag 

15 of some sort associated with that bitmap or that line. That cache tag has 

16 been sent back to the client. The client is instructed by the server to collect 

17 that bitmap and write it into its off-screen buffer. 

1 8 That is crucial to understanding the arguments that we've made 



19 throughout. And in fact, up until the examiner's answer, we had understood 

20 the examiner to be saying that all of the prior art references ~ or I should 

21 say not all ~ the two major prior art references, which are CLAPP and 

22 Hanko, both taught a server instructing a client to form an off- screen buffer 

23 and to store data in that off-screen buffer. 

24 I can go through why neither CLAPP nor Hanko teach that, teach a 

25 server instructing a client to do that. In the answer ~ this appears for the 
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1 first time ~ to be in the examiner's Answer for the first time. The examiner 

2 appears to have realized that Hanko and CLAPP do not teach that and 

3 instead relies on a broader reading of the claim, which tries to read out this 

4 server requirement in order to make Hanko and CLAPP apply. 

5 JUDGE HOMERE: Let's turn to what the prior art teaches. From 

6 what I understand from the record, the prior art teaches you have two 

7 computers that are communicating, right, they're sharing information. So 

8 one computer accesses or opens up an application and allocates opening that 

9 application, allocates an off- screen to a buffer, right, an off- screen surface to 

10 a buffer, and then sends communication to the other computer and the other 

1 1 computer operates in the same fashion and it pretty much transmits whatever 

12 image that they're looking at to the other computer? 

13 MR. LANZA: I think that's right. Your Honor. I believe we're 

14 talking about CLAPP right now, which is a videoconferencing system which 

15 performs as you describe. There are ~ in CLAPP, it's a symmetric system in 

16 that there is a local host and a remote host connected by a communication 

17 channel, which is number 82 in CLAPP, and the local host is described as 

18 creating a local off-screen buffer into which it writes local pixel data. 

19 The local host and the remote host are able to share their off-screen 

20 buffers and then the remote host will copy into its display buffer from its 

21 own off-screen buffer. So what is missing from CLAPP is that in CLAPP, 

22 the local host never instructs the remote host to one, create an off-screen 

23 buffer, because it already exists. The remote host has to have it because it's 

24 a symmetrical system. 
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1 JUDGE HOMERE: There's nothing in the claim that says that 

2 requires the server to instruct the client to create an off-screen buffer. It 

3 instructs the client to select ~ off- screen buffer. And so wouldn't it be 

4 reasonable for one to construe the teaching of CLAPP as saying that once the 

5 client, the first client transmits the image to the other client, a buffer, an off- 

6 screen buffer is allocated subsequently to receiving that message from the 

7 other client? 

8 MR. LANZA: If you were to interpret CLAPP that way ~ I don't 

9 believe that CLAPP does that. I believe that CLAPP always has that buffer 

10 allocated at startup time. For the sake of argument, if I were to interpret 

1 1 CLAPP to disclose that when the local host sends data to the remote host, 

12 that upon receipt of that data the remote host creates its own buffer, the local 

13 host is not instructing the client that ~ it's not instructing the remote host to 

14 create that buffer. 

15 JUDGE HOMERE: Why not? 

16 MR. LANZA: It's simply ~ it's simply sending data. Your point 

17 though, I thought, was a good one and an accurate one and I appreciate you 

1 8 raising it, which is the claim language is actually instructing the client to 

19 select a first memory region for allocation to the off-screen buffer. Again, 

20 that ~ one could argue whether selection or creation are different. They are, 

21 because in the ~ in our specification, we talk about having two areas in the 

22 memory region and being able to select between them for the data. But the 

23 transfer of data from CLAPP ~ in CLAPP from the remote host to the local 

24 host, is merely just that; it's a transfer of data. 
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1 JUDGE HOMERE: Yeah, but the allocation of a buffer, if you will, 

2 in the remote host is subsequent to receiving that data. Therefore ~ 

3 JUDGE COURTENAY: Well, it actually says in column 12 of 

4 CLAPP, lines three and four, that the communication may proceed 

5 subsequently to or concurrently with the processing step. So the 

6 transmission of the data can happen concurrently or subsequent to what 

7 happens at the local host. 

8 I've been reviewing CLAPP, Figure 12, and particularly columns 1 1 



9 and 12, and in Figure 12, in block 652, we have a disclosure that at the 

10 remote site there's this copying of local pixel data to the remote off-screen 

1 1 window buffer. But we don't have a real teaching that tells us when that 

12 buffer's allocated, more specifically, how it's allocated, other than as you 

13 raised the point that we have symmetric systems here. 



14 We know they're symmetric because in column 12, lines seven 

15 through eight, it discloses ~ CLAPP discloses a remote host computer 

16 system 264 preferably operates visual conferencing application software 

17 substantially similar to that operating on a local host computer system 244. 

18 JUDGE HOMERE: My question still stands though, in the sense that, 

19 well, is that a possible interpretation of that teaching? Wouldn't it be 

20 reasonable for one of ordinary skill in the art to say that, well, I have this 

21 local client and then upon opening an application, it allocates a buffer, sends 

22 ~ transmit data to a remote ~ a remote client and then the remote client 

23 allocates ~ subsequently to receiving that data, allocates an off-screen buffer 

24 in order to establish the communication? 
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1 MR. LANZA: I respectfully submit, Your Honor, that it's not a 

2 reasonable interpretation and this is why. In the system of CLAPP, both 

3 hosts have to be operating the same software, so the software has to behave 

4 the same whether it's a local host or a remote host. That off-screen buffer 

5 that is created on one of the hosts, I don't care which one, is created when 

6 the videoconferencing system is set up, because the off-screen buffer is used 

7 to move data in and out of the windows on the computer that is attached to 

8 the videoconferencing host. So that off-screen buffer is always going to be 

9 there when the system is operating. 

10 JUDGE HOMERE: So you are assuming ~ you are assuming that 

1 1 both of them ~ both the local and the remote clients launched that same 

12 application before they start communicating, therefore, because ~ from the 

13 teaching of CLAPP, upon launching that application, that buffer is created, 

14 right? 

15 JUDGE COURTENAY: Actually, that's ~ he's pointing to column 1 1 

16 and we do have information about how the local host computer system 

17 allocates the buffer at lines 32 through approximately 36 of column 1 1. At 

18 line 32, it discloses ~ the CLAPP reference discloses the user at step 628 

19 then selects a local active application window 602 from the menu 600 for 

20 sharing with a remote conferencing site. 

21 JUDGE HOMERE: That is the local - 

22 JUDGE COURTENAY: The local host computer system 244 at step 

23 630 preferably allocates an appropriate amount of system memory to 

24 accommodate a local on-screen window buffer 604. So we know how the 

25 local host system allocates its memory and we also have information that 
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1 these two systems, the remote host and the local, are symmetric. They 

2 operate the same way. We don't appear to have information as to the timing 

3 of how this happens at the remote site beyond what we have with respect to 

4 the local host. 

5 JUDGE HOMERE: And my question, as a way to fill the gap, as far 

6 as the information that's missing from this reference, wouldn't it be 

7 reasonable to say that while you start with the local host first, you launch 

8 that application, the buffer's allocated, you transmit data over to the remote 

9 host, and the remote host allocates the buffer? 

10 MR. LANZA: If it is reasonable to assume that, that is not a teaching 

11 of this specification. Now you're requiring the specification to act as an 

12 obviousness reference, because this specification does not teach, as required 

13 by the law, that command to set up the off-screen buffer at the remote host. 

14 An examiner is relying on CLAPP to teach that one of the ~ one of the hosts 

15 instructs the other host to create the local buffer, which it doesn't do; it 

16 doesn't teach that. 

17 JUDGE HOMERE: What I'm saying is, if the local buffer is created, 

18 if the remote buffer is created subsequently to receiving the data from the 

19 local host, wouldn't that be construed as ~ the creation of the remote buffer, 

20 the buffer at the remote host becomes construed as being created based on an 

21 instruction received from the local host? 

22 MR. LANZA: Yes, Your Honor, but could also be construed as being 

23 created, because the remote host has decided that it wants to create an off- 

24 screen buffer. It may receive an indication from the local host that data is to 

25 be shared, and it elects not to set up an off- screen buffer. It may elect to just 
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1 direct that data directly into the on-screen buffer because of various 

2 conditions. Usually off-screen buffers are used when windows are clipped, 

3 and you don't want to show some of the data that's actually in the window, 

4 so you write that to an off-screen buffer. 

5 There's no ~ there's no teaching at all on how the local host is 

6 going to decide whether or not to set up an off-screen buffer and there's 

7 certainly ~ 

8 JUDGE HOMERE: The remote host, you mean? 

9 MR. LANZA: I may have misspoke, I'm getting confused with local 

10 host or remote host at this point. They're both hosts. But whichever ~ 

1 1 whichever system is getting the data from the other system, there's no ~ 

12 there's no teaching at all on how or whether that system decides to set up an 

13 off-screen buffer. We just know that there is ~ there is later some discussion 

14 about the remote host could have an off-screen buffer there. 

15 JUDGE COURTENAY: The CLAPP reference doesn't appear to 

16 disclose exactly what triggers this allocation. If I look at Figure 12, step 

17 628, the user selects this local active window application and then 

18 subsequent to that step, we have this memory allocation step 630. There's 

19 really no information that I can see from this reference that tells us what 

20 triggers this allocation. 

21 MR. LANZA: I agree, and that's our position, that this does not teach 

22 one of the systems instructing the other to create or to select memory for an 

23 off-screen buffer. We don't know ~ CLAPP doesn't teach how that gets 

24 selected. 
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1 JUDGE HOMERE: But you would agree though ~ you would agree 

2 though if ~ if the creation of the buffer at the remote host is done subsequent 

3 to receiving that image or that data from the remote -- the local host, that 

4 could be construed as an instruction that's creating the buffer at the remote 

5 host upon receiving an instruction from the local host? 

6 (Pause) 

7 JUDGE COURTENAY: Don't you argue in your Briefs that the mere 

8 receiving of data is not receiving an instruction? 

9 MR. LANZA: Yes, and I'm trying to decide how to respond to Your 



10 Honor's question because it could be construed to be that, but I would -- 1 

1 1 would argue that a command . . . , we've made a distinction in paragraph two 

12 between graphical data and other types of network traffic. And so an 

13 instruction is not graphical data. So an instruction is not data that might 

14 come from an off-screen buffer such as a bit-mapped ~ bit-mapped 

15 graphical data, encoded bitmap, glyphs or line data. 



16 It's something different that is an explicit indication to the other host, 

17 you need to set up an off-screen buffer because I'm about to throw ~ I'm 

18 about to throw data at you and I want you to store it in there. 

19 JUDGE HOMERE: Do you have anything else? 

20 MR. LANZA: I do. The examiner, in his reply, has admitted that the 

21 other two elements of claim 1 are not in CLAPP. I think it is worth speaking 

22 briefly about Hanko, because the examiner refers to Hanko, which is a Sun 

23 Microsystems patent, that talks about efficient methods of displaying tiled 

24 graphical data at a remote computer. 
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1 It appears that from Hanko, Hanko teaches that while off-screen 

2 buffers are good, off-screen buffers aren't available at all devices and so this 

3 is a technique for efficiently replicating tile data in systems where one does 

4 not want to use or cannot use an on-screen buffer. We make these 

5 arguments in the Brief as well. 

6 As you know from our Briefs, I don't believe Hanko should be 

7 considered as prior art, as analogous prior art, at all because one of ordinary 

8 skill in the art looking for ways to improve off-screen buffering techniques 

9 in a client server system would not look to a reference that in its beginning 

10 pages says, off-screen buffers are wonderful, but lots of computers don't 

1 1 have off-screen buffers so we're going to talk about techniques for doing this 

12 without using off-screen buffers. 

13 Hanko also, therefore, does not teach instructing a client to select a 

14 first memory region to be used as an off-screen buffer, because it teaches 

15 away from off-screen buffers. It doesn't want you to use off-screen buffers. 

16 In fact, it assumes that you're going to receive ~ that the client is going to 

17 receive that graphical data from the server and write it directly to the on- 

1 8 screen buffer and use some techniques to replicate that tiled data over and 

19 over and over again. 



20 In fact, the techniques that he uses is that with respect to bit-mapped 

21 data. It sends some attributes of that data. It sends the size. It sends the 

22 repetition number, and then it uses ~ the client uses that information to 

23 repeat the bit-mapped tile. 

24 So in fact, the second step, which is transmitting indicia of a graphical 

25 data, the examiner's taken the position that indicia can be almost anything. 
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1 However, if you look at our specification at paragraph 71, we talk about 

2 what indicia is and it's about midway down through the paragraph. But it 

3 says that the server agent issues a command to the client agent to form the 

4 off-screen surface in the client's volatile memory 114. The command is then 

5 accompanied by an encoded representation of the off- screen surface if this is 

6 the first instance of the off-screen surface or by an index or a fuzzy key if 

7 the off-screen surface has been previously transmitted. 

8 The indicia that is recited to in that step of claim 1, and a similar step 

9 in claim 12, is not attribute data about the graphical data that is coming 

10 across, but is really referring to cache indicia, such as a cache tag or a fuzzy 

1 1 key, which we talk about earlier in the specification. That point is reinforced 

12 by claim 2, which then further recites that step ~ that claim 1 further 

13 comprises the step of specifying a plurality of attributes for the graphical 

14 data. 

15 So Hanko does not teach or suggest instructing a client to select 

16 memory to form an off-screen surface. It also doesn't teach or suggest 

17 transmitting indicia of the graphical data to the client. I would submit that 

1 8 Hanko also doesn't teach or suggest instructing the client to copy the 

19 graphical data. At best, what Hanko teaches is that graphical data is sent to 

20 the client with instructions on how to copy. 

21 Hanko describes or discloses that the client itself makes the decision 

22 to copy that bitmap glyph over and over and over again in its memory. So to 

23 sum up, because I believe I'm running out of time, it's our position that the 

24 preamble is limiting, that CLAPP does not teach or suggest instructing the 
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1 client to select a first memory region. At best, it teaches that there are two 

2 memory regions that are used for off-screen buffers. 

3 The examiner admits that the other two steps of claim 1 and similar 

4 steps in claim 12 are not taught or suggested by CLAPP. Hanko does not 

5 teach or suggest these elements, for the reasons I've stated, and Pierson, 

6 which we haven't talked about much, but I think is a fairly minor reference 

7 here, also does not teach or suggest these. So any combination of these 

8 references is going to fail to teach or suggest each and every element of 

9 claims 1 and 12. So it's our view that the rejection of claims 1 through 20 is 

10 not obvious in view of these references, is improper and ought to be 

1 1 reversed. 

12 JUDGE HOMERE: Anything else? All right, thank you very much. 

13 MR. LANZA: Thank you. 

14 (Whereupon, at 1 1 :20 a.m., the proceedings were concluded.) 
15 
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